1. Field of the Invention
The invention relates to object oriented processors and processor systems. More particularly, the invention relates to an object oriented processor or processor system which communicates with a script server. Script servers according to the invention may be centralized or distributed locally.
2. State of the Art
Modern computers permit seemingly simultaneous execution of many operations by interrupting the microprocessor periodically to execute several software threads in turn. For example, as a user types on a keyboard, the input from this peripheral to the microprocessor is seemingly simultaneously displayed by the microprocessor on a video display peripheral. In reality, the microprocessor is interrupted periodically from displaying output on the video display in order to obtain input from the keyboard. It is only because the microprocessor operates at a very high speed that there is an illusion of simultaneity. In a more complex processing system, there may be many threads vying for microprocessor attention at any time. For example, in a desktop multimedia computer, several peripheral devices must be controlled by the microprocessor in a seemingly simultaneous manner in order to produce the proper results and different operations such as displaying video and playing audio must be handled by separate threads. The programming environment in a system having so many threads is incredibly complex. The system software must be written to schedule microprocessor attention to each thread, assign priority to each thread and allow peripherals to interrupt the microprocessor at appropriate times. The system software must then schedule tasks for the microprocessor in response to the interrupts from various peripherals.
In addition to scheduling problems, software in a multi-tasking (multi-threaded) system is difficult to debug. Single stepping techniques cannot be used, since different threads may depend on the results of other threads, and only a single thread can be operational during single stepping.
The handling of interrupts by the microprocessor is determined in part by the bus protocol and in part by the design of the microprocessor itself. Typically, the bus is designed to work with a particular microprocessor or group of microprocessors; and peripheral devices are designed to work with a particular bus. Moreover, each microprocessor-bus system handles interrupts in a different way. This makes it difficult, if not impossible, to adapt program code used on one microprocessor-bus system for use on another.
In order to relieve the host processor from performing every task, multiprocessor systems have been proposed. Some multiprocessor systems are successful in dividing tasks among processors when the tasks are well defined. For example, it is not uncommon to divide tasks between a data processor and a signal processor in systems which deal with signals and data in real time. It is more difficult to divide data processing tasks among several data processors. The operating system must decide which tasks will be performed by which processor and must schedule tasks so that processors do not remain idle while waiting for new tasks or while waiting for other processors to complete tasks so as to provide needed results. Consequently, there has been very little success in developing a general purpose multiprocessor system and there is no standard programming language for programming a multiprocessor system.
U.S. Pat. No. 5,095,522 to Fujita et al. discloses an object-oriented parallel processing system which utilizes xe2x80x9cconcept objectsxe2x80x9d and xe2x80x9cinstance objectsxe2x80x9d. The system utilizes a host processor and a plurality of general purpose processors which are programmed by the host processor. The host user must program (generate concept and instance objects) for each processor before parallel processing can begin. Fujita et al. considers this aspect of their system to be a feature which allows dynamic changes in the functionality of each of the processors. However, this aspect of their system greatly complicates the host processor software.
Similarly, U.S. Pat. No. 5,165,018 to Simor describes a system in which xe2x80x9cnodesxe2x80x9d are provided with generic configuration rules and are configured at runtime via resource definition messages from the control node. Simor considers this aspect of his system to be an advantage which, among other things, xe2x80x9cisolates the hardware from the softwarexe2x80x9d and xe2x80x9callows programs to be written as if they were going to be executed on a single processor.xe2x80x9d In addition, Simor""s system permits programs to be xe2x80x9cdistributed across multiple processors without having been explicitly designed for that purpose.xe2x80x9d
Both Fujita et al. and Simor utilize general purpose processors and attempt to isolate the hardware from the software, freeing the programmer to write code as if it were being executed on a single processor. However, as mentioned above, writing multithreaded software for a single processor is very complex. Neither Fujita et al. nor Simor offer any solution for this complexity.
3. Related Inventions
Related application Ser. No. 08/525,948 approaches the problem of distributed processing in a manner which is completely different from that of either Fujita et al. or Simor. The system disclosed in the ""948 application utilizes processors which have been pre-programmed with functionality for a specific purpose and thereby integrates hardware with software. The developer chooses specific hardware (object oriented processors) in a manner similar to choosing specific software objects. This approach requires that the developer be very aware of the hardware used in the system, but frees the developer from writing much of the code used to implement the system. Accordingly, the developer need only write a minimal amount of relatively high level code to link the pre-programmed object oriented processors which contain statically stored code for performing specific tasks. This approach is based on the belief that writing and de-bugging code is more time consuming and more expensive than linking together processors which contain pre-written, bug-free code. This approach enables rapid system development, relieves the host processor of many scheduling tasks, simplifies de-bugging, enables cross-platform support, allows software emulation of hardware devices, as well as providing other advantages.
According to the ""948 application, object oriented processors communicate with each other and/or with the host processor via the exchange of high level messages. This earliest implementation of the communication protocol required that the host poll at least some of the object oriented processors (i.e. those responsible for processing input data) to determine the availability of data. This was eventually found to detract from the goal of simple coding as the host code had to be written in a manner that would scan all possible input sources on a frequent basis. It was eventually decided that this polling created an undesirable overhead and coding complication. Since many of the originally developed object oriented processors operated in real time, the polling scan rate could be high and thus the overhead could be substantial. In addition, the early communication protocol did not provide information about the source of the data. This was instead derived by specific information requests by the host. Thus, several message exchanges might have been required before both data and source were determined.
Related application Ser. No. 08/683,625 discloses a distributed processing system one or more object oriented processors are embodied as a collection of components on a single ASIC chip. This related application includes an enhanced communication language where the host need not poll the object oriented processors and where messages from one processor to another include source and destination addresses. This communication protocol can be said to be xe2x80x9cevent drivenxe2x80x9d.
As used herein, the term xe2x80x9cobject oriented processor arrayxe2x80x9d means a collection of object oriented processors where each object oriented processor incorporates a separate hardware processor, or a collection of object oriented processors where each object oriented processor is embodied as a virtual processor sharing the same hardware processor, or any combination of discrete hardware processors and virtual processors.
It is therefore an object of the invention to provide an object oriented processor array with enhanced post-manufacture configurability.
It is an additional object of the invention to provide an object oriented processor array which utilizes an enhanced communication protocol which conserves bandwidth and allows the developer/user to choose a level of coding simplicity in exchange for object latency.
In accord with these objects which will be discussed in detail below, an object oriented processor array of the present invention includes a readable memory containing a library of configurable (programmable) functions (also referred to as objects) and a writable memory in which objects are instantiated and configured. More specifically, the object oriented processor array includes a system functionality (system object) which is automatically instantiated in writable memory at power-up, which calls other objects to be instantiated in writable memory in response to commands from a host processor or a boot ROM, and which maintains an active task list and other information about instantiated objects. The object oriented processor array according to the invention further includes a communications interface, an input message processor, and an output message processor. The communications interface allows the object oriented processor array to communicate with other object oriented processor arrays and/or with a host processor or script server. The output message processor preferably includes an output flow manager for handling messages from processor objects in the array and a central output registry for queuing messages. According to a presently preferred embodiment, the object oriented processor array is embodied as a virtual machine which is formed from software which runs on a microprocessor. Therefore, the software which embodies the object oriented processor array is provided with a timing kernel which simulates parallelism and a memory manager which allocates memory to objects when they are instantiated.
During operation, a message to a particular instantiation of an object is parsed by the input message processor which scans the active task list name table to find the index to the active task list the pointer to the object instantiation addressed. The object receives the message from the input message processor and the index. The object uses the index and the active task list data space table to find which instantiation of itself is being addressed. Messages from an instantiation of an object are placed in the output message header part of its RAM and a request for registration is sent to the central output registry. The output registry maintains a queue of pointers to messages in output message header parts. The queue is scanned by one or more output flow managers which form output messages from the information held in the output message header parts.
According to one embodiment of the invention, one or more object oriented processor arrays are coupled to a central script server or host processor. Messages which result from data events in any of the processor objects are sent to the central script server for processing. The central script server parses the messages it receives from processor objects and executes a script which has been written for this type of data event. The script usually results in the sending of a message to another processor object on the same array or on a different array than the array containing the processor object having the data event. The flow of messages is preferably based on an event-reaction architecture as described in co-pending Ser. No. 09/004,174.
According to another embodiment, one or more object oriented processor arrays are provided with local, internal script servers. In this xe2x80x9cdistributed scriptingxe2x80x9d embodiment, communications are controlled according to the event-reaction protocol by providing the output message processor with additional functionality to register and queue data events and an event script look up table to determine which events relate to internal messages. The input message processor is provided with additional functionality to queue and buffer messages destined for objects in the array.
According to other preferred aspects of the invention, a high level language is provided for communication between object oriented processors and a host processor during set-up and during operation. The high level language according to the invention includes support for the event-reaction protocol, an efficient addressing scheme, better use of bandwidth and simplified host parsing. According to a presently preferred embodiment, the high level language messages are exchanged in packets of variable length with a well defined header. The header includes addressing information, an indication of the type of message which follows, an indication of the method or data type, and an indication of the length of the remaining data in the packet. The high level language is self-aligning, simple, and robust.
As mentioned above, the object oriented processor arrays according to the invention are embodied in many alternative constructions including running software on a microprocessor, field programmable gate arrays, multiple microprocessors, and other hardware devices.
Additional objects and advantages of the invention will become apparent to those skilled in the art upon reference to the detailed description taken in conjunction with the provided figures.